PATENT COOPERATION TREATY 



From the 

INTERNATIONAL SEARCHING AUTHORITY 



see form PCT/1SA220 



PCT 



WRITTEN OPINION OF THE 
INTERNATIONAL SEARCHING AUTHORITY 

(PCT Rule 43WS.1) 



(day,inonttfy0ar) see form PCTdS A,2\ 0 (second sheet) 



Applicant's or agent's file reference 
see form PCT4SA£20 



FOR FURTHER ACTION 

See paragraph 2 below 



International application No. 
PCTCB200«04551 



international filing date {dayfaonth/year) 
28.10.2004 



Priority date (dayfamnthyear) 
28.10.2003 



Internationa) Paterrt Classification (IPC) or both national 
G06F9/445 



Applicant 

SYMBIAN SOFTWARE LIMITED 



This opinion contains indications relating to the following items: 

IS! Box No . I Basis of the opi rtion 
E! Box No. II Priority 

□ Box No. Ill Non-establishment of opinion with regard to novelty, inventive step and industrial applicability 

□ Box No. IV Lack of unity of invention 

13 Box No. V Reasoned statement under Rule 43fofe.l fa)(i) with regard to novelty, inventive step or industrial 

applicability: citations and explanations supporting such statement 
O Box No V! Certain documents cited 

□ Box No. VI I Certain defecls in the international application 

□ Box No. VIII Certain observations on the international application 
FURTHER ACTION 

If a demand for international preliminary examination is made, this opinion will usually be considered to be a 
written opinion of the International Preliminary Examining Authority ("IPEA"). However, this does not apply where 
the applicant chooses an Authority other than this one to be the I PEA and the chosen fPEA has notifed the 
International Bureau under Rule 66.1e/stb) that written opinions of this International Searching Authority 
will not be so considered. 

If this opinion is, as provided above, considered to be a written opinion of the IPEA, the applicant is invited to 
submit to the IPEA a written reply together, where appropriate, with amendments, before the expiration of three 
months from the date of mailing of Form PCTdSAfi20 or before the expiration of 22 months from the priority date, 
whichever expires iater. 

For further options, see Form PCT.-1SA520. 

For further details, see notes to Form PCT/ISAJ220. 



Name and mailing address of the ISA: 



European Patent Office 
D-80298 Munich 

Tel +49 89 2399 - 0 Tx: 523656 epmu d 
Fax: +49 83 2399 - 4465 



Authorized Officer 



Kalejs, E 

Telephone No. +49 89 2399-691 9 



WRITTEN OPINION OF THE 
INTERNATIONAL SEARCHING AUTHORITY 



International application No, 
PCTOB2004tf)04551 



Box No. I Basts of the opinion 

1 . With regard to the language, this opinion has been established on the basis ot the international application in 
the language in which it was tiled, unless otherwise indicated under this item. 

□ This opinion has been established on the basis of a translation from the original language into the following 
language , which is the language of a translation furnished for the purposes of international search 
(under Rules 12.3 and 23.1(b)). 

2. With regard to any nucleotide and/or amino acid sequence disclosed in the international application and 
necessary to the claimed invention, this opinion has been established on the basis of: 

a. type of materia!: 

□ a sequence listing 

□ table(s) related to the sequence listing 

b. format of material: 

□ in written format 

□ in computer readable form 

c. time of filing/furnishing: 

□ contained in the international application as filed. 

□ filed together with the international application in computer readable form. 

□ furnished subsequently to this Authority for the purposes of search. 

3. □ In addition, in the case that more than one version or copy of a sequence listing andfor table relating thereto 

has been filed or furnished, the required statements that the information in the subsequent or additional 
copies is identical to that in the application as filed or does not go beyond the application as filed, as 
appropriate, were furnished. 

4. Additional comments: 



Form PCT4SA/237 (January 3004) 



WRITTEN OPINION OF THE 
INTERNATIONAL SEARCHING AUTHORITY 



International application No. 
PCT/GB2004J004551 



Box No. » Priority 



1 . H The following document has not been furnished: 

B copy of the earlier application whose priority has been claimed (Rule 43b/s.1 and 66.7(a)). 

□ translation of the earlier application whose priority has been claimed (Rule 43&S.1 and 66.7(b)), 

Consequently it has not been possible to consider the validity of the priority claim. This opinion has 
nevertheless been established on the assumption that the relevant date is the claimed priority date. 

2. □ This opinion has been established as if no priority had been claimed due to the fact that the priority claim 

has been found invalid (Rules 436&1 and 64.1). Thus for the purposes of this opinion, the international 
tiling date indicated above is considered to be the relevant date. 

3. □ It has not been possible to consider the validity of the priority claim because a copy of the priority document 

was not available to the iSA at the time that the search was conducted (Rule 1 7.1). This opinion has 
nevertheless been established on the assumption that the relevant date is the claimed priority date. 

4. Additional observations, if necessary: 



Box No. V Reasoned statement under Rule 43o/s.1(a)(i) with regard to novelty, inventive step or 
industrial applicability; citations and explanations supporting such statement 

1. Statement 

Novelty (N) Yes: Claims 

No: Claims 1-10 

Inventive step (IS) Yes: Claims 

No: Claims 1-10 

Industrial applicability (IA) Yes: Claims 1-10 

No: Claims 



2. Citations and explanations 
see separate sheet 
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Reasoned statement with regard to novelty, inventive step or industrial 
applicability; citations and explanations supporting such statement 

1 . The following document is referred to in this communication; the numbering will be 
adhered to in the rest of the procedure: 

01 : "FORWARDER DYNAMIC LINK LIBRARIES AS A METHOD FOR 

SERVICING SOFTWARE" IBM TECHNICAL DISCLOSURE BULLETIN, IBM 
CORP. NEW YORK, US, vol. 38, no. 1 1 , 1 November 1995 (1995-1 1-01), 
pages 407-408, XP000547408 ISSN: 0018-8689 

2. Lack of novelty, Article 33(2} PCT 

3.1 The present application does not meet the requirements of Article 33(2) PCT, 
because the subject-matter of claim 1 is not new in the sense of Article 33(2) PCT. 

The document D1 discloses (the references in parentheses applying to this 
document): 

A method of providing a dynamic link library for linking between functions and an 
executable program in a computing device, the method comprising providing the 
dynamic link library as: 

- a first part for linking the executable program to one or more first functions (page 
407, figure 2. The primary DLL 1 and primary DLL 2 are interpreted as the first 
part); and 

- an extension part for causing the executable program to link one or more further 
functions, additional to the one or more first functions, via the extension part (page 
407, figure 2. The Forwarded DLLs 1-3 are interpreted as the extension part). 

3.2 Dependent claims 2-8 do not contain any features which, in combination with the 
features of any claim to which they refer, meet the requirements of the PCT in 
respect of novelty and/or inventive step, the reasons being as follows: 

The features disclosed in claims 2-8 are well-known per se and represent, in fact, 
merely a few of several straightforward possibilities from which the skilled person 
would select, in accordance with circumstances, without the exercise of inventive 
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skill, in order to solve the problem posed. 

3.3 Claims 9 and 1 0 claim the subject-matter of claims 1 -8 in the form of a device and 
computer software, respectively, and therefore the same objections apply also to 
these claims. 
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iiiiilillilll 





Primary 




Primary 


OU 1 




DLL 2 


vl.O 




vl.O 



r/a 



FIG. 2. 



Disclosed is a method for servicing and packaging enhancements for a software product, which is 
shipped with one or more large, primary Dynamic I -inV Libraries (DLL) and several smaller, sec- 
ondary forwarder DLLs. Calls to the primary code are made through the forwarders. Software 
fixes and enhancements arc provided by replacing individual forwarder entries with a corrective 
function inside a secondary DLL. 

Most applications, together with modem operating systems, use one or more DLLs to 
supply commonly-used functions efficiently. A DLL may be used as a forwarder to one or more 
other DLLs, with code bemg linked to a forwarder DLL, instead of to the primary DLL, imple- 
menting the desired functions. The loader resolves the forwarder by loading the primary DLL 
and by setting the call address in the calling code directly to the address of the code in the primary 
DLL 

With the presently disclosed method, software products imple merited using forwarder DLLs 
may be serviced or enhanced by simply replacing forwarders in the forwarder DLLs with correc- 
tive functions. These corrective functions may replace existing functions by reimplementing them 
without calling the original functions, or they may enhance functions by adding a prologue and/or 
an epilogue to the call. 

Fig. 1 is a block diagram showing an application shipped with an executable 1 (EXE), two 
primary DLLs 2, and three forwarder DLLs 3. 
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Forwarder Dynamic Link Libraries as a Method tor Servicing Software - Continued 

Fig. 2 is a block diagram showing the same basic components with newer versions of two of 
the forwarder DLLs. New code 4 has been added to these forwarder DLLs, as depicted by outer 
boxes. In general, some calls by the application into the secondary DLL are still forwarded, some 
cause the execution of new corrective code in a forwarder DLL, and some execute new corrective 
code in addition to being forward. 

The use of this method provides advantages if it becomes necessary to ship corrected or 
enhanced software to customers. Fewer disks arc generally required to ship such software, since 
the size of the forwarder DLLs, even with the corrective functions, is likely to much smaller than 
that of replacement primary DLLs. Furthermore, with properly designed and documented inter- 
faces, fixes and enhancements in the forwarder DLLs may be written by software developers with 
no access to the underlying primary code. Even if the primary code is encumbered by royalties 
and copyrights, the fixes and enhancements need not be so encumbered. 
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Disclosed is a method for d>T2amieaUy intercepting imported procedure calls without requiring 
alterations to the source code of the importing or exporting applications. 

Software organizations have a critical need to analyze the programming interfaces provided 
by both operating systems and applications. For example, function and system test organizations 
need to trace procedure input and output paratneters, as weB as return codes, to determine the 
code path coverage being attainted and to detemnae whether procedures are functioning properly. 
Performance organizations are interested in measuring the length of time a procedure requires to 
accomplish each of its taste. Customer support needs to defennme program logic flow to get a 
better understanding of why a customers apphcaiinn fiats. 
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The conventional methods for meeting these needs are either to incorporate procedure 
wrappers within the application invoking (importing) the programming interface, or alternately to 
incorporate hooks in the procedures within the application defining (exporting) the programming 
interface. While these wrappers and hooks can easily traps procedure input and output parame- 
ters and return codes, and can easily measure timing by capturing procedure entry and exit times, 
an underlying problem with each of these methods is that modification is required to source code 
of the importing or exporting application, along with recompilation, relinking, and redistribution 
of the finished product. The nature of this problem eliminates the possibility of intercepting and 
analyzing procedures imported by off-the-shelf applications, as the source code is generally una- 
vailable. 

The presently-disclosed method relies on the fact that operating systems supporting dynamic 
hiking require a means for resolving dynamic link references, to successfully load applications 
which import procedures. This resolution may be achieved by generating a relocation record for 
each imported procedure that contains the module name and the procedure name or ordinal. 
Another method, which reduces or optimizes link time, generates a relocation record for each 
imported procedure that contains the index into a module name table as well as an ordinal or an 
index into a procedure name table. In this way, only a single module name string per module and 
a single procedure name string per procedure is required, regardless of the number of invocations. 
Another method, which reduces or optimizes load time, generates code for each imported proce- 
dure, with the code jumping to common code invoking the procedure. This method requires only 
a single relocation record per procedure, regardless of the number of invocations, with the relo- 
cation record using one of the previously-described methods to identify the module and proce- 
dure. Combinations or variations of these methods ate also possible, but the name of the module 
exporting the procedure must reside somewhere within the application importing the procedure. 
A subsequent change of the name causes a new module to be loaded instead of the old module, 
with corresponding procedures being called in the new module instead of in the old module. 



198 



IBM Technical Disclosure Bulletin Vol. 39 No. 01 January 1996 



(PCTJ95) 700 IBM Technical Disclosure Bulletin 
39(1996) January, No. \, Armonk, NY, US 



Dynamic Interception of Imported P 

Wrapper U&rory Module Defmilions f^e: 



e Caiis - Continued 



IMPORTS 




taporfProeedure 




EXPORTS 


impcrtPrseedtfre 


# Ordinof 



FIG. 4. 



Importing Application: 



Code Segment: 
importProc«dure(); 



fixup Record Table: 
Ncme/Ofdinol 



Exporting Application: 



Code Segment: 
ImporfProcsdureO; 



Import Nome Tobfe: 
EXP0RTU8RARY 



FIG. 5, 



Fig. I is & block diagram showing how these concepts are applied in the linear executable 
module format of OS/2*, with the import module same table deuniag the module name strings 
imported through dynamic link references. Each imported procedure called by an OS/2 applica- 
tion has a matching relocation record, which references the appropriate string within this table. 



The presenth/H&sclosed method also relies on the fact that operating systems that snpport 
dynamic Unking require a means of defining where an exported procedure resides within a 
module, information on where the procedure begins within a particular code segment is usually 
grouped together in some form of table. Some operating systems have developed means to 
forward procedures from one module to another, allowing a procedure to be imported from one 
module even though the code physically resides in a different module. Subsequently, procedures 
which do not need to be mtercepted can be forwarded to the true exporting application by both 
importing and exporting the procedures. While forwarding is not needed for the presently- 
disclosed method, it provides an advantage in that only the procedures of interest need to be inter- 
cepted. Without a form of forwarding mechanism, every procedure within a module must be 
intercepted 

Fig. 2 is a Hock diagram showing how these concepts are applied within the linear execui* 
able module format of OS/2, with an entry table containing object and offset information that is 
used to resolve relocation references to the entry points within a module. The forwarder entry of 
the entry table is an exported entry point that resolves 1© an imported reference. Thus, the 
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module contains no code associated with the forwarded entry point, and the final target address of 
toe forwarded entry is contained in another module. 



Fig. 3 is a block diagram illustrating the intercepting and analyzing of imported procedures 
by the presently-disclosed method. Procedure wrappers are incorporated into the source code of 
the wrapper library, which is a Dynamic link library (DLL) having an entry table containing an 
entry for each entry in the entry table of the exporting application's DLL. The wrapper library 
contains a procedure wrapper for each procedure of interest in the exporting application. The 
wrapper library intercepts these procedures by placing the names of the wrapper procedures into 
the wrapper library's module definitions file. 



Fig. 4 is a block diagram illustrating how the presently disclosed method passes on inter- 
rupted procedures without intercepting them. The wrapper library does not contain a procedure 
wrapper for any procedure not of interest in the exporting application. Such a procedure is for- 
warded by placing the procedure name in both the imports and exports section of the wrapper 
library's module definitions file. Once the wrapper library is available, the imported procedures 
can be intercepted and analyzed by simply replacing the name of the exporting library within the 
import module name table of the importing application with the wrapper library's name. 
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Fig. 5 is a block diagram showing the interface between importing and exporting applica- 
tions before the import module name table is modified. 

Fig. 6 shows the interface of Fig. 5 after the import module name table is modified. If the 
name of the wrapper library is the same length as the name of the exporting library it is replacing, 
the name need only be overwritten in the import module name table of the importing application. 
Otherwise, the entire import module name table, and everything in the importing application fol- 
lowing the table, need to be adjusted and rewritten, along with the appropriate entries in the 
linear executable header. 

With the wrapper library available, having its name in the import module name table of the 
importing application, all procedures imported by the application are redirected first through the 
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wrapper library. If a procedure wrapper exists, control is passed to the wrapper, then to the 
exporting application, and then back through the wrapper. If a procedure wrapper does not exist, 
control is passed directly to the exporting application through a forwarder. As a result, when 
wrapper insertions, modifications, or deletions are required, only the wrapper library needs to be 
recompiled, relinked, and distributed; both the importing and exporting applications remain 
unchanged. 

To discontinue intercepting the procedures, the wrapper library's name within the import 
module name table of the importing application is changed back to the name of the exporting 

application. 

* Trademark of IBM Corp. 



Vol.39 No. 01 January 1996 



IBM Technic*! Disclosure Bulletin 



20t 



